ci: publish stable hastegeo wheel automatically on merge to main - #120
Merged
Joaquín Rivero (jQuinRivero) merged 2 commits intoAug 11, 2026
Merged
Conversation
Merging a PR into `main` that touches `hastelib/` produced a validated wheel artifact but never published it. The `publish-stable` job in `hastegeo-publish.yml` was gated on two repository variables (`HASTEGEO_PUBLISH_ENABLED` and `HASTEGEO_RELEASE_APPROVAL_CONFIGURED`) plus the protected `hastegeo-release` environment. Neither variable was ever set, so the job was silently skipped on every merge and stable publication has been off since the pipeline shipped — stable stops at 1.0.26 while twelve 1.0.27rcN prereleases accumulated. The per-release approval was a rollout gate, not a permanent control. It is also redundant: the `main` ruleset is active with no bypass actors and requires an approving review plus CodeQL and gitleaks, so nothing reaches `main` unreviewed. The PR review that lands the commit is the release approval. Drop the `HASTEGEO_RELEASE_APPROVAL_CONFIGURED` condition and the `environment: hastegeo-release` line from `publish-stable`. `HASTEGEO_PUBLISH_ENABLED` remains as the kill switch. `HASTEGEO_RELEASE_APPROVAL_CONFIGURED` is intentionally left unset: it also gates the destructive RC deletion job in `rc-cleanup.yml`, which keeps the protected environment and its reviewer requirement. Behavior change: every merge touching `hastelib/` now cuts a patch release. Use `workflow_dispatch` with an explicit `bump` or `set_version` for minor/major. Update the workflow policy test accordingly — `hastegeo-build.yml` runs that suite as a build step, so leaving it asserting the old gate would break the wheel build itself. `test_scheduled_cleanup_is_report_only` continues to assert that RC deletion keeps the protected environment. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d383b5e1-d1c6-4f7b-b8b1-0ef6b8f69c78
Copilot started reviewing on behalf of
Joaquín Rivero (jQuinRivero)
August 11, 2026 16:52
View session
Contributor
There was a problem hiding this comment.
Pull request overview
Automates stable hastegeo wheel publication after reviewed changes merge into main, retaining the repository-variable kill switch.
Changes:
- Removes the stable-release environment approval gate.
- Preserves approval gating for destructive RC cleanup.
- Updates workflow policy tests and release documentation.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.github/workflows/hastegeo-publish.yml |
Enables automatic stable publication. |
.github/workflows/README.md |
Documents release behavior and controls. |
hastelib/README.md |
Updates the package release process. |
hastelib/tests/build/test_release_workflows.py |
Verifies the revised publication policy. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Address PR #120 review feedback. The spec is the source of truth in this repo, but the workflow change left it asserting a control that no longer exists. Update README.md, design.md, plan.md, and test-plan.md to record that stable publication is automatic on merge to main, gated only by HASTEGEO_PUBLISH_ENABLED, and that the protected hastegeo-release environment plus HASTEGEO_RELEASE_APPROVAL_CONFIGURED now scope to the destructive RC deletion job only. The superseded bring-up gate is recorded rather than deleted. Also remove an incorrect instruction from .github/workflows/README.md: it told operators to use workflow_dispatch with bump/set_version for minor/major releases, but hastegeo-publish.yml only accepts push and same-repository pull_request upstream events, and its trusted resolver receives neither input. That path publishes nothing. Document the gap explicitly instead.
RC artifacts readyAll branch deployment references use the same RC tag:
|
RC artifacts readyAll branch deployment references use the same RC tag:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Merging a PR into
mainthat toucheshastelib/builds and validates a wheel,but never publishes it. Stable publication has been off since the release
pipeline shipped — the latest stable wheel is
1.0.25/1.0.26while twelve1.0.27rcNprereleases have accumulated on thehaste-binariesrelease.Nothing was failing. The build workflow is credential-free by design and did its
job; the downstream
publish-stablejob inhastegeo-publish.ymlwas simplyskipped on every merge by its own
if:condition:Neither repository variable was ever set. Behind them sat a second gate, the
protected
hastegeo-releaseenvironment requiring a per-release reviewer.Most recent example: build run
31346902355
succeeded and its publisher run
31346931090
reported
prepare: success,publish-stable: skipped.Change
Remove the redundant approval gate from
publish-stable:HASTEGEO_RELEASE_APPROVAL_CONFIGUREDclauseenvironment: hastegeo-releaseHASTEGEO_PUBLISH_ENABLEDas the kill switchThe per-release approval was a rollout mechanism (see
spec/features/hastegeo-ci-pipeline/plan.md: "Merge with publication disabled…then enable and manually approve the first release"), not a permanent control.
It is also redundant: the
mainruleset isactivewith zero bypass actorsand requires an approving review, resolved review threads, CodeQL and gitleaks.
Nothing reaches
mainunreviewed, so a second sign-off re-approves analready-reviewed commit.
RC deletion stays gated
HASTEGEO_RELEASE_APPROVAL_CONFIGUREDis deliberately left unset. It alsoguards the destructive RC-deletion job in
rc-cleanup.yml, which retains theprotected
hastegeo-releaseenvironment. This PR un-gates stable publicationonly.
test_scheduled_cleanup_is_report_onlystill asserts that carve-out.Behavior change
Once
HASTEGEO_PUBLISH_ENABLED=trueis set (after this merges), every mergetouching
hastelib/cuts a patch release. The next one resolves1.0.26→1.0.27, publishinghastegeo-1.0.27-py3-none-any.whland creatingtag
hastegeo-v1.0.27.Use
workflow_dispatchwith an explicitbumporset_versionforminor/major releases.
Security posture
Unchanged apart from the removed approval. The publisher still runs trusted
default-branch code via
workflow_run, re-resolves the version from trustedpolicy, revalidates the downloaded wheel before publishing, and cannot overwrite
assets (no
--clobber;already_publishedmakes reruns a no-op).Tests
hastegeo-build.ymlrunspython -m unittest discover -s hastelib/tests/buildas a build step, so the policy test asserting the old gate had to be updated in
the same change — otherwise this fix would break the wheel build it is fixing.
test_rc_is_automatic_but_stable_is_approval_gatedbecomestest_rc_and_stable_are_both_automatic_but_kill_switched, assertingpublish-stablehas noenvironment:, still requiresHASTEGEO_PUBLISH_ENABLED, and no longer referencesHASTEGEO_RELEASE_APPROVAL_CONFIGURED.All 34 tests pass locally.
Follow-up after merge
Set the repository variable — stable publication stays off until then:
Order matters: setting it before this merges would leave
publish-stableblocked on the environment approval and could queue a pending deployment.